The transmission of media data, such as audio and video data, over a network is becoming more common. Users can now watch all types of media data, from a pre-recorded show to a live concert, online over the Internet or on their wireless cellular networks. Because the media data tend to take up large amounts of memory, their transmission requires vast resources. As a result, the media data are generally streamed over the network. Streaming enables the media data to be played in real time as the data are being downloaded over the network as opposed to storing the entire file first to permanent memory. Basically, media data is first divided into a sequence of frames at the sender. Each frame in the sequence contains a small portion of the media data and each frame is assigned a timestamp to indicate its position in the media data, which is generally relative to the beginning of the media. Media data frames are then sent one or a few at a time, and the receiver, such as a media player, buffers the sent frames and outputs the frames according to a timeline reconstructed based on the timestamps carried in the received frames. Streaming of the media data generally avoids the delay entailed in downloading an entire file and then playing it with a helper application at a later time.
Streaming of the media data is also becoming more prevalent within a cellular wireless setting. In fact, wireless broadcast and/or multicast services are now one of the major new features in the Third Generation Partnership Project (3GPP) and the third Generation Partnership Project 2 (3GPP2) communication networks. A major technical problem, however, arises with streaming in a wireless system. Specifically, one problem is that wireless networks tend to be more unstable than landline networks, because the wireless signal can be temporarily blocked or shadowed as the receiver moves between different environments. For example, the wireless signal can be temporarily blocked or shadowed by tall buildings in a city or tunnels through mountains or under rivers. Sometimes, the receiver can miss several minutes of the media data that may not be recoverable as the receiver may be unable to receive for up to several minutes. Although this is far less of an issue with wired Internet Protocol multimedia services, they can nevertheless suffer from similar but minor shadowing problems due to such conditions as transit congestion in a local network. All this, in turn, often causes degradation of the service quality or interruptions of the service in both wired and wireless networks.
To address these problems, one proposed method, known as Forward Error Correction, adds extra bits specifically for error correction to any character or code block of the data prior to transmission. If the transmission is received in error, the correction bits are used to check and repair the data. This method, however, only addresses data corruption caused by bit errors during data transfer or the loss of a few frames of data; it does not correct a total signal blockage.
Another proposed solution is a technique known as jitter buffers, which is widely used in many real-time media receivers such as RealPlayer® and QuickTime®. A jitter buffer is a shared data area where voice packets can be collected, stored, and sent to the voice processor in correctly spaced intervals according to their originally assigned sequence numbers. Variations in packet arrival time, called jitter, can occur because of network congestion, timing drift, or route changes. The jitter buffer, which is located at the receiving end of the voice connection, intentionally delays processing of the arriving packets so that the end user experiences a clear connection with very little sound distortion. Although this method can combat minor temporal jitters, it is impractical for correcting large delays (e.g., more than one minute). This method is also incapable of compensating for the data loss. Moreover, the use of jitter buffers tends to force the receiver to wait at the start of the media stream until the jitter buffer has been filled, but users of the wireless broadcast or multicast services may have very little tolerance for this start latency.
Still another solution, which is generally done in a point-to-point communication scenario to compensate for data loss, is to retransmit the lost data. This method, however, is impractical in a broadcast or multicast scenario due to the complexity of end-to-end synchronization between the sender and multiple receivers. Moreover, the retransmission method requires means for sending feedback from the data receiver to the sender that may not exist in most broadcast or multicast scenarios. Another proposed method is to use interpolation, which is generally used with wireless networks, but this is also not workable because it is ineffective to combat losses of consecutive frames.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help improve understanding of various embodiments of the present invention. Also, common and well-understood elements that are useful or necessary in a commercially feasible embodiment are typically not depicted in order to facilitate a less obstructed view of these various embodiments of the present invention.